Cryptext x64 0.9a - Fortschrittsdialog-Korrektur
=================================================

ACHTUNG
-------
Wie 0.9 kann 0.9a bei Ver- UND Entschlüsselung die jeweilige Quelldatei
löschen, wenn "Originaldatei beibehalten" NICHT aktiviert ist. Für Abbruch- und
Fehlertests weiterhin nur entbehrliche Kopien verwenden.

Was 0.9a korrigiert
-------------------
0.9 hatte drei sichtbare Probleme im neuen Fortschrittsdialog:

1. Der Datei-Rahmen war deutlich höher als beim originalen Cryptext 3.
2. Der Fortschrittsbalken erschien praktisch sofort/ständig als 100% gefüllt.
3. Der Balken war unter dem v6-Common-Control-Look blau und segmentiert; der
   Abbruch-Knopf entsprach noch nicht dem Flat-Look des Hauptdialogs.

0.9a korrigiert ausschließlich diese UI-/Fortschrittsschicht. Das CT64FILE-v1-
Format und der bestätigte Ver-/Entschlüsselungspfad bleiben unverändert.

Kompakte Cryptext-Geometrie
---------------------------
Die Anordnung folgt jetzt der Originalreferenz:

  Dateien werden verschlüsselt... / entschlüsselt...

  + Datei [1 von 3] ----------------------------------+
    D:\Pfad\aktuelle_Datei.ext
  +---------------------------------------------------+

  [ Fortschrittsbalken                       ] [Abbruch]

  Ver-/Entschlüsseln und Schreiben der Temp-Datei
  On-Disk-Verifikationsdurchlauf
  Rename, Zeitstempel/Attribute und ggf. Löschen der Quelle

Der Gruppenrahmen läuft wieder kompakt über die Breite. Der Abbruchknopf steht
wie beim alten Cryptext neben dem Balken und nicht neben dem Datei-Rahmen.

Fortschrittsfehler aus 0.9
--------------------------
Die Range bleibt intern 0..1000:

  0..700    Phase 1
  700..990  Phase 2
  990..1000 Phase 3

In 0.9 wurde PBM_SETPOS mit einem FASM-Win64-invoke aufgerufen, bei dem ECX als
späteres Argument benutzt wurde, obwohl RCX gleichzeitig den HWND aufnehmen
musste. Je nach Macro-Auswertungsreihenfolge konnte dadurch der niedrige DWORD-
Teil des Fensterhandles statt der berechneten Position in wParam landen. Dieser
sehr große Wert wurde von der Progressbar auf ihr Maximum geklemmt: optisch 100%.

0.9a kopiert die berechnete Position zuerst nach R8D und ruft SendMessageW danach
direkt gemäß Win64-ABI auf. Damit bleibt die eigentliche 0..70 / 70..99 / 99..100
Berechnung unverändert, erreicht die Progressbar jetzt aber mit dem richtigen
Wert.

Grüne native Progressbar
------------------------
0.9a zeichnet den Balken NICHT selbst. Es bleibt die native Windows-Klasse
"msctls_progress32".

Für den Cryptext-3-Look wird:
- PBS_SMOOTH gesetzt,
- nur für dieses einzelne Control das v6-Theme via SetWindowTheme deaktiviert,
- PBM_SETBARCOLOR verwendet.

Der Grünton wurde aus dem vom Benutzer unter Windows 10 aufgenommenen originalen
Cryptext-3-Screenshot übernommen: RGB(6,176,37).

Das Hauptfenster und die übrigen Controls behalten ihre bisherige Darstellung.

Phasenanzeige
-------------
Unverändert zu 0.9:
- aktuelle + bereits erledigte Zeilen: normal/schwarz
- noch nicht begonnene Zeilen: Windows-typisch ausgegraut

Dadurch ist die letzte schwarze Zeile gleichzeitig die aktuell laufende Phase.

Empfohlene Tests
----------------
1. Große Datei (>300 MiB) verschlüsseln.
   - Balken darf NICHT sofort voll sein.
   - Phase 1 muss von ungefähr 0 bis 70% laufen.
   - Phase 2 muss anschließend von ungefähr 70 bis 99% laufen.
   - erst der Abschluss erreicht 100%.

2. Dieselbe große .$#!-Datei entschlüsseln.
   - gleicher sichtbarer Fortschritt in beiden Phasen.

3. Mehrere Dateien auswählen.
   - Datei [1 von n], [2 von n], ...
   - Balken wird bei jeder neuen Datei auf 0 zurückgesetzt.

4. Optik prüfen.
   - Datei-Rahmen deutlich kompakter und ungefähr wie Cryptext 3.
   - Balken glatt und grün statt blau/segmentiert.
   - Abbruch-Button flach.
   - drei Statuszeilen weiterhin vollständig lesbar.

5. Abbruch in Phase 1 und Phase 2.
   - Sicherheitsverhalten muss exakt wie 0.9 bleiben:
     unvollständige Temp entfernen, Quelle vor Commit erhalten.

6. Regression:
   - 0 Byte
   - 1 Byte
   - 4 MiB
   - 4 MiB + 1 Byte
   - >300 MiB
   - Einzeldatei und Batch
   - Originaldatei beibehalten an/aus
   - gemerktes Passwort
   - falsches Passwort / manipulierte Datei

Unverändert
-----------
- CT64FILE-v1-Byteformat
- PBKDF2-HMAC-SHA-256, Writer 600.000 Iterationen
- AES-256-GCM via Windows CNG
- 4-MiB Writer-Chunks
- eigener Salt / Nonce-Präfix / Schlüssel pro Datei
- vollständiger zweiter On-Disk-Verifikationsdurchlauf
- Temp -> Flush -> Verify -> Rename -> Metadaten -> optional Delete
- Batch-Fortsetzen Ja/Nein
- SecureInput / Session-Passwort / virtuelle Tastatur

Legacy Cryptext 3.x bleibt in 0.9a deaktiviert.
